The Windows Embedded and Windows operating systems include functionality that can prevent the content of a storage medium from being changed. In a typical example, it may be desirable to prevent the operating system image, which may be stored on a particular disk partition or on flash media, from being changed at runtime. To accomplish this, Windows provides a file-based write filter which operates at the file level and a block-based write filter (or enhanced write filter) that operates at the block level to redirect all writes that target a protected volume to a RAM or disk cache called an overlay. This overlay stores changes made to the operating system at runtime but is removed when the device is restarted thereby restoring the device to its original state.
FIG. 1 illustrates how a write filter 110 can be employed to prevent the contents of a protected volume on disk 100 from being modified. Disk 100 is intended to generally represent any type of physical storage medium (or volume). In accordance with the Windows architecture, a driver stack consisting of file system driver 111, volume manager 112, and disk driver 113 sit atop disk 100, and I/O manager 120 manages the flow of I/O requests through the driver stack. An application (not shown) can employ file/directory management APIs 160 to invoke a service of system services 130 (e.g., by calling ReadFile, WriteFile, CreateFile, etc. on a particular file) which will result in I/O manager 120 creating an IRP for the request. This IRP will then be passed down through the driver stack.
As depicted in FIG. 1, write filter 110 is positioned at the top of the driver stack and will therefore be able to process an IRP prior to the IRP being passed down to the lower level drivers. Write filter 110 can be configured to detect writes targeting a protected volume and redirect them to overlay 140 rather than allowing them to be passed down the driver stack unchanged. As a result, the write will actually occur in overlay 140 rather than to disk 100. Write filter 110 can be further configured to detect reads that target content that was previously redirected to overlay 140 and redirect these reads to overlay 140. In this way, even though it will appear to the application that the content of disk 100 is being updated, the updates are actually being temporarily maintained in overlay 140. The contents of overlay 140 can be maintained until the operating system is restarted or until an explicit command is received to discard the contents of the overlay.
The size of the overlay employed by the Windows write filter is static and cannot be changed without rebooting. For example, the UWF_OverlayConfig.SetMaximumSize function allows the size of the overlay, in megabytes, to be specified. However, when this function is called, it has no effect on the size of the overlay during the current session. Instead, the specified size of the overlay will not be applied until the next session.
One problem that results from the static size of the overlay is that the system will be automatically rebooted if the overlay becomes full. The user will not be presented with an option to reboot in this scenario. Over time, it is likely to become full and force the reboot of the system. As a result, the user experience can be greatly degraded when a write filter is employed. Also, if the size of the overlay is set too high, the system may not have enough RAM left to run multiple applications or even the operating system.
U.S. patent application Ser. No. 15/422,012, titled “Mechanism To Free Up The Overlay Of A File-Based Write Filter” (the '012 application) describes techniques for employing an overlay-managing write filter in conjunction with the write filter to monitor files that are stored in the overlay and move files that are not currently being accessed to thereby minimize the size of the overlay. If a request is made to access a moved file, the overlay-managing write filter can modify the request so that it targets the location of the moved file rather than the location of the original file on the protected volume. In this way, the fact that modified files are being moved from the overlay can be hidden from the write filter. As a result, the effective size of the overlay will be increased while still allowing the write filter to function in a normal fashion.
FIGS. 2 and 3 and the following discussion is taken from the description of the '012 application and is intended to provide an overview of one environment in which the present invention can be implemented. FIG. 2 is based on FIG. 1 and illustrates how an overlay-managing write filter 200 can be used in conjunction with write filter 110 to manage artifacts (e.g., files, folders, registry entries, etc.) that are stored in overlay 140. More particularly, overlay-managing write filter 200 can monitor which artifacts in overlay 140 are not currently being accessed and can move them to an overlay cache 240 on disk 100.
For purposes of this description, it will be assumed that overlay 140 and overlay cache 240 are implemented on two separate volumes. For example, overlay 140 can be implemented on the C: volume while overlay cache 240 can be implemented on the D: volume. Therefore, when overlay-managing write filter 200 moves an artifact from overlay 140 to overlay cache 240, it will be a cross-volume move. Also, if overlay cache 240 is implemented on a separate volume from the protected volume, write filter 110 will not modify any operations targeting overlay cache 240.
In some embodiments, this moving of artifacts can be carried out by employing a copy component 200a of overlay-managing write filter 200 that may preferably run in user mode. After moving an artifact to overlay cache 240, overlay-managing write filter 200 can cause the artifact to be discarded from overlay 140 thereby reducing the size of overlay 140 to prevent overlay 140 from becoming full. To ensure that the modifications that were made to the artifact are not lost, overlay-managing write filter 200 can monitor I/O requests to allow it to intercept a request to access an artifact that has been moved to overlay cache 240 and cause the request to be redirected to overlay cache 240. In this way, the fact that overlay-managing write filter 200 moves artifacts to overlay cache 240 will be hidden from write filter 110.
FIG. 3 provides an example of various components of overlay-managing write filter 200. As shown, overlay-managing write filter 200 can include a filtering component 201 and an overlay managing component 202. Filtering component 201 can generally represent the portion of overlay-managing write filter 200 that functions as a filter driver in the device stack for disk 100 (or, more specifically, in the stack for the protected volume). Accordingly, filtering component 201 can be configured to process IRPs that target artifacts on the protected volume. Importantly, because overlay-managing write filter 200 is positioned above write filter 110, filtering component 201 will be able to process these IRPs before they are handled by write filter 110.
Overlay managing component 202 can generally represent the portion of overlay-managing write filter 200 that is configured to interface with write filter 110 and possibly copy component 200a for the purpose of managing which artifacts are moved from overlay 140 to overlay cache 240 and for ensuring that subsequent requests to access a moved artifact can be handled in the proper manner (e.g., by identifying and modifying requests that target a moved artifact so that the moved artifact (which would be the modified version of the artifact) will be accessed from overlay cache 240 rather than from its permanent location on disk 100). The distinction between filtering component 201 and overlay managing component 202 is for illustrative purposes only and any suitable configuration of the functionality of overlay-managing write filter 200 may be employed.
As shown in FIG. 3, overlay-managing write filter 200 can also maintain a map 203 which identifies which artifacts have been moved to overlay cache 240 as well as the specific location in overlay cache 240 where these moved artifacts are stored. Overlay managing component 202 can be configured to update and maintain map 203 based on which artifacts are moved to overlay cache 240. Overlay managing component 202 and/or filtering component 201 may also employ map 203 to properly redirect an I/O request that targets a moved artifact.
In the Windows operating system, a user mode application typically employs one of the MoveFile APIs to perform a file rename. For example, the MoveFile function takes as input the existing filename and the new filename. To implement the rename, the operating system will open the existing file (e.g., using IoCreateFileEx and specifying the existing filename as input) to obtain the file's information (the “source”), open (or create) the target of the rename (e.g., using IoCreateFileEx and specifying the new filename as input) to determine whether the source and target of the rename operation are on the same volume, and then use the source file's information to modify the target file so that it is a replica of the source file (e.g., using ZwSetInformationFile).
Of relevance to the present discussion, this process will result in three IRPs being passed down the I/O stack: (1) an IRP_MJ_CREATE for the first call to IoCreateFileEx which opens the source file; (2) an IRP_MJ_CREATE for the second call to IoCreateFileEx which opens/creates the target file; and (3) an IRP_MJ_SET_INFORMATION that updates the target file with the source file's information.
By default, if the source and target of a rename operation are not on the same volume, the operating system will fail the rename. The reason for failing the cross-volume rename is because it would require copying the file to the target volume rather than simply updating the file system data structure to reflect a new path to the existing file. To make this determination, the operating system will extract the targeted volume from the results of the second IRP_MJ_CREATE and compare it to the source volume obtained from the results of the first IRP_MJ_CREATE. If the target volume does not match the source volume, the operating system will fail the rename operation and will therefore not send the IRP_MJ_SET_INFORMATION.
To force the operating system to implement the rename across volumes, the user mode application can set the MOVEFILE_COPY_ALLOWED flag. In such cases, if the operating system determines that the source and target volumes are not the same, it will still proceed with the rename by copying the source file's information to the target file's information using the IRP_MJ_SET_INFORMATION. The MOVEFILE_COPY_ALLOWED flag is not available in the MoveFile function but is available in the MoveFileEx, MoveFileWithProgress, and MoveFileTransacted functions.
How the operating system implements renames creates a number of difficulties when an overlay optimizer is employed. For example, if overlay cache 240 is implemented on a separate volume (e.g., D:) from the protected volume (e.g., C:), any attempt to rename a file that exists in overlay cache 240 will likely be a cross-volume rename. For example, if a user mode application attempts to rename a file from C:\folder1\file.txt to C:\folder2\file.txt, when in fact the file is stored in D:\folder1, overlay-managing write filter 200 would cause the first IRP_MJ_CREATE to open the file in D:\folder1 which would not match the targeted C: volume. If the user mode application called MoveFile to initiate this rename, the operating system will fail the rename with STATUS_NOT_SAME_DEVICE. To address this issue, the user mode application could be modified to employ the MOVEFILE_COPY_ALLOWED flag, but this is not always possible or desirable.